home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 483 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.1 KB
  1. Date: Mon, 27 Jun 94 02:36 MET DST
  2. From: chris@buran.fb10.tu-berlin.de (Christian Nieber)
  3. To: gem-list@world.std.com
  4. Subject: Re: Big-Cursor-Block, Dialog Box Proposal
  5. Precedence: bulk
  6.  
  7. Timothy:
  8.  
  9. > )Another thing... Couldn't someone put up a preliminary voting system for
  10. > )things like Control-A or the big cursor block question. If there is a 
  11. clear
  12. > )majority for one side, which will hopefully support existing standards,
  13. > )this should settle these annoying discussions and help increase the
  14. > )signal/noise ratio.
  15. > 
  16. > Which block-system is used may be beyond the scope of this proposal, but
  17. > since both systems will be using subsets of the SAME shortcut standard,
  18. > we should make sure that neither one is disadvantaged in favor of the
  19. > other or has dangerous shortcuts.  In the Big-cursor system Ctrl-A can be
  20. > dangerous, while in the other, it's merely annoying.
  21.  
  22. The block paradigm _does_ make a difference for shortcut. The 
  23. Macintosh/NeXT guidelines are designed for the big-cursor paradigm. When a 
  24. cursor exists simultaneously with a block
  25.   - you need a "hide block" function
  26.   - delete/BS probably can't be used for deleting the block
  27.   - setting block start/end in the menu makes sense
  28.   - so does copy/move to cursor position
  29.  
  30. In essence, additional shortcuts are needed that would better be used for 
  31. something else in the big-cursor paradigm.
  32. Since we want to set standards for other things as well, we should better 
  33. put the big-cursor paradigm in the standard now, since it's well 
  34. established on the ATARI and in all other major GUI's. Those who still want 
  35. to implement the other sort of blocks (damn, isn't there a good name for 
  36. it? ) can make up their own shortcuts.
  37. There isn't even an established standard for the other sort of block. I 
  38. occasionally have to use old programs that use this (GFABasic, TurboASS, 
  39. Tempus), but everyone has a different set of shortcuts for the block, and 
  40. none of them understands ^X/^C/^V.
  41.  
  42.  
  43. Mark Baker:
  44. > >> undo             Undo last command        Edit
  45. > >> UNDO             Redo last command        Edit
  46. > >> Command-undo     Multi-level undo         Edit
  47. > >> Command-UNDO     Step-wise undo           Edit
  48. > >
  49. > > I don't see why we need more than two. BTW is there any program on the 
  50. >ATA > RI now that supports multi-level undo?
  51.  
  52. > There's a graphics package that does IIRC. Anyway it is a potentially > 
  53. useful
  54. > feature, so should have a standard shortcut.
  55.  
  56. I feel misunderstood. More precisely, apps that only support undo and redo 
  57. can use Undo alternatively for both. Those with multi level-Undo can use 
  58. Undo for step-wise undo and Control or Shift - Undo for Step-wise redo.
  59.  
  60. > > too). Hide means hide application, quite like Mag!X does it, i.e. it stays
  61. > > in memory, may even do calculations and can be brought back to the screen
  62. > > by doubleclicking its icon again (this is different in Mag!X). Hidden
  63. > > applica- tions can be recognised by not having the "..." at the bottom of
  64. > > their icon. But I don't know how to do that in MultiTOS or Mag!X, since
  65. > > AFAIK neither of them provides a system call for that.
  66.  
  67. > What's wrong with just iconifying?
  68.  
  69. Doesn't work for MagiC (yet), and the menu bar will stay there.
  70.  
  71. Ken:
  72.  
  73. >                   ** Dialog box look and feel proposal **
  74. >              ** Proposal by Ken Hollis  of Bitgate Software **
  75.  
  76. This is all very nice, but you can't expect every application programmer to 
  77. implement all this. We can't make up for all things ATARI has neglected. 
  78. Since modal non-window dialogs are considered outdated, but there is zero 
  79. support from the system for window dialogs, every professional software 
  80. developer was practically forced to make his own dialog handler, and few 
  81. professional programs use PD libraries.
  82. If someone made a dialog library (that should of course support modeless 
  83. dialogs) that would aready be better, but I still wouldn't want to adapt 
  84. all my dialog handling, because it's a lot of work, and there is always the 
  85. problem of finding bugs in other people's code. If it can't be part of the 
  86. system, such complex things shouldn't be required by a standard.
  87.  
  88.  
  89. About Revert/Reload/Abandon etc.:
  90.  
  91. Apple's Human Interface Guidelines suggest "Revert to Saved"
  92.  
  93.  
  94.    Christian (R.O.M. logicware)
  95.